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Abstract 


!  At  many  universities  and  institutions  throughout  the  world  it  is  now  very 
common  to  have  a  network  of  computers,  each  running  the  Berkeley  4.3BS-D 
version  of  UNIX  or  an  equivalent  version  such  as  ULTRIX.  This  paper  is 
to  help  users  ofj  these  versions  of  UNIX  to  explore  and  experiment  with  the 
interprocess  communications  and  networking  facilities.  We  present  a  series 
of  client/ server  programs  that  can  be  used  as  a  model  for  writing  distributed 
applications.  Wff  describe  how  users  can  test  and  experiment  with  these 


programs.  Readers  are  assumed  to  be  familiar  with  the  C  programming 


language  and  some  version  of  UNIX. 
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1  Introduction 


Currently,  many  universities  and  research  organizations  have  a  network  of  comput¬ 
ers  each  running  4.3BSD  version  of  UNIX  or  a  compatible  version  such  as  ULTRIX 
or  DG/UX.  A  major  addition  to  these  versions  of  UNIX  is  the  Interprocess  Com¬ 
munications  ( IPC)  facilities  that  allow  unrelated  processes  on  the  same  or  different 
machines  to  communicate  and  exchange  messages.  This  make  it  possible  to  write 
distributed  applications  and  provide  a  better  environment  for  users  to  collaborate 
and  access  remote  resources  and  utilities  (See  for  example,  Abdel- Wahab  et.  al. 
(1.2]). 

In  this  paper  we  introduce  the  important  basic  features  of  the  IPC  facilities  and 
show  how  to  write  distributed  applications  based  on  these  facilities.  The  users  axe 
assumed  to  be  familiar  with  some  version  of  UNIX  (see  for  example,  Kemighan  and 
Pike  [4]),  and  the  C  programming  language  (Kemighan  and  Ritchie[5]).  A  tutorial 
introduction  to  IPC  is  given  in  Coffield  [3]  and  Sechrest  [8].  For  a  comprehensive 
coverage  see  Leffler  et.  el.  [6]. 

There  are  several  domains  of  communication,  the  most  frequently  used  ones 
are  the  internet  domain  ( INET)  and  the  UNIX  domain.  The  INET  domain  em¬ 
ploys  the  DARPA  standard  protocols  TCP/IP  and  UDP/EP  (Leiner  et.  el.  [7]). 
The  UNIX  domain  is  basically  used  for  efficient  communication  between  unrelated 
processes  residing  on  the  same  machine.  The  INET  domain  allows  processes  run¬ 
ning  on  different  machines  (as  well  as  on  the  same  machine)  to  communicate.  In 
most  cases  the  INET  domain  is  preferable  to  the  UNIX  domain,  since  applications 
written  in  the  INET  domain  may  run  on  any  configurations  of  machines. 

In  each  domain,  there  are  two  methods  of  communication:  stream  and  deca¬ 
gram.  In  the  stream  method  the  two  communicating  processes  have  to  establish 
a  connection  or  a  virtual  circuit  before  they  can  exchange  messages.  This  style  of 
communication  provides  bidirectional,  reliable,  sequenced  and  unduplicated  flow 
of  data.  On  the  other  hand,  datagram  communication  docs  not  require  any  con¬ 
nection  between  the  two  processes  as  each  message  is  addressed  individually  but 


there  is  no  guarantee  regarding  delivery,  sequencing,  or  duplication  of  messages. 
The  choice  between  the  two  methods  is  usually  based  on  the  application  semantics 
and  the  required  performance. 

This  paper  is  organized  as  follows.  Section  2  is  concerned  with  the  INET 
domain,  the  first  part  deals  with  stream  communication  and  the  second  with 
datagram  communication.  Each  part  is  described  by  giving  a  pair  of  server  and 
client  programs.  The  programs  sire  tested  using  two  terminals  (or  two  windows 
of  a  single  terminal)  connected  to  two  different  hosts  or  to  a  single  host.  Section 
3  is  devoted  to  the  UNIX  domain.  Section  4  deals  with  the  cases  where  a  server 
communicates  with  two  or  more  clients  and  input  multiplexing  is  required.  Section 
5  is  our  conclusion. 

2  Internet  Domain 

In  this  section  we  describe  how  two  processes  in  the  INET  domain  communicate 
with  each  other.  The  first  step  for  a  process  to  communicate  with  another  is  to 
create  a  socket.  A  socket  is  an  end  point  of  communication  and  is  created  with 
socket  system  call: 

s  =  socket(domain,  type,  protocol); 

For  example,  to  create  a  stream  socket  in  the  internet  domain  we  use: 

s  =  socket(AFJNET.  SOCK-STREAM.  0); 

Here,  we  specify  0  in  place  of  the  protocol  arguments  so  the  system  will  use  the 
default  standard  protocol. 

We  distinguish  between  the  two  communicating  processes  by  calling  one  the 
server  and  the  other  the  client.  The  server  process  has  to  “bind”  its  socket  to  a 
known  “name”  so  that  the  client  process  can  use  this  name  to  establish  a  connec¬ 
tion  with  the  server.  The  name  format  in  the  INET  domain  consists  of  two  parts 
host-address  and  port-number.  The  host-address  is  a  32-bit  network  wide  address 
assigned  to  the  machine  (for  example,  128.109.135.1  is  the  address  of  a  machine  at 


North  Carolina  State  University  called  “ncsu”  and  128.109.136.82  is  for  a  machine 
at  UNC-Chapel  Hill  called  “unc”).  The  port-number  is  an  integer  in  the  range 
0-50,000  (the  subrange  0-1024  is  reserved  for  privileged  use,  for  example,  the  re¬ 
mote  login  program  rlogxn  uses  port  number  513  and  the  file  transfer  program  ftp 
uses  port  number  21).  To  bind  a  socket  s  to  a  name  we  use: 
bind(s.  name,  sizeof(name)): 

nama  is  a  structure  where  its  fields  axe  to  be  filled  out  appropriately  as  in  the 
following  example. 

struct  sockaddr.in  name ; 


name. sin_f ami ly  *  AF_INET; 
name.sin_addr.s_addr  *  INADDR.ANY; 
name . sin_port  *  0; 
bindCs.  Jmame.  slzeof (name) ) ; 

Here,  the  constant  INADDR_ANY,  means  any  valid  address  of  the  host.  If  we  know 
the  host  address,  e.g,  128.109.136.82,  we  use  it  as: 

name .  sin_addr .  s_addr  »  inet_addr  ( "  128 . 109 . 136 . 82" )  ; 
and  if  the  host  name  is  known,  e.g.,  “ncsu”  it  is  used  as: 

struct  hostent  *hp; 

hp  *  gethostbyname("ncsu") ; 

bcopy(hp  ->  h.addr,  fc(name . sin.addr . s_addr) .  hp->h_length) ; 

To  choose  a  port  number,  we  either  use: 
name . sln.port  *  0; 

in  which  case,  the  system  selects  the  next  free  port,  or  if  you  know  the  number  of 
a  particular  free  port,  e.g.,  1234,  it  is  used  as: 
name . sln.port  *  1234; 

If  the  system  selects  a  free  port,  the  selected  port  number  may  be  displayed  as 
follows: 


length  *  sizeof (name) ; 
getsockbyname (s ,  fcname,  fclength) ; 
printf ("%d" ,  ntohe (name . «in_port) ) ; 

After  the  server  creates  a  socket  and  binds  it  to  an  INET  name,  it  executes: 
listen(s.  n); 

to  specify,  as  n,  the  maximum  number  of  outstanding  connections  to  be  queued 
awaiting  acceptance  by  the  server.  This  system  call  is  non-blocking,  it  just  sets 
up  the  socket  and  makes  it  ready  for  accepting  connections. 

The  client  process  creates  its  own  socket,  sc,  but  it  does  not  need  to  bind  it  to 
a  name  like  the  server.  Then  it  initiates  a  connection  to  the  server  process  using 
the  connect  system  call: 

connect(sc.  &server_name.  sizeof(server_name)): 

When  the  connection  request  arrives  at  the  server,  it  is  accepted  using: 
si  =  accept(s.  0.  0): 

Where  si  is  an  “auxiliary”  socket  descriptor  to  be  used  in  communicating  with 
the  client  process.  This  system  call  causes  the  server  process  to  be  blocked  waiting 
for  the  client  process  to  be  connected.  The  server  may  accept  other  connections 
as  shown  in  Fig.  1. 

Once  a  connection  is  established  between  a  client  and  a  server,  data  may  flow 
in  both  directions.  The  client  may  send  data  using: 

send(sc.  data,  sizeof(data).  0): 
and  the  server  may  receive  the  arrived  data  using: 
recv(sl.  buffer.  sizeof(buffer)),0): 

When  the  server  and  the  client  are  done  with  their  conversation,  each  may  close 
its  end  of  the  connection  using  the  close  call: 

close(socket): 

Example  Programs 

In  this  paper  we  choose  the  names  of  our  example  programs  to  reflect  their 
functions  using  the  following  abbreviations: 


/ :  for  INET, 

U :  for  UNIX, 

V  :  for  Virtual  circuit, 
D  :  for  Datagram 
5 :  for  Server, 

C  :  for  Client 


Each  program  includes  a  “deP  file  that  contains: 

finclude  <sys/types .h> 

# include  <ays/eocket .h> 

* Include  <sys/un.h> 

♦include  <stdio.h> 

♦include  <netinet/in.h> 

♦include  <netdb.h> 

♦include  <signal.h> 

♦include  <sys/tiae.h> 

♦define  TRUE  1 

2.1  INET  Virtual-circuit  programs 

In  order  to  test  and  practice  with  the  concept  of  communication  between  two 
processes  in  the  INET  domain  using  a  virtual  circuit  connection,  we  wrote  two 
programs  in  Fig.  2:  a  server  program  IVS  and  a  client  program  IVC. 

The  server  process  IVS  starts  by  creating  a  socket  ss  (lines  10-14),  then  binds 
it  to  any  free  port  in  the  host  machine  (lines  16-23),  advertises  the  selected  port 
number  by  displaying  the  message:  socket  has  port  ♦  ....  and  finally  listens 
for  a  connection  attempt  by  the  client  process  IVC  (line  33).  When  the  client 
process  attempts  to  connect  to  the  server  process,  the  connection  is  accepted  in 
socket  si  (line  34).  Following  the  connection  establishment,  the  server  enters  a 
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a 


0  (include  "d eT 

1  mainO 

2  { 

3  fat  sa.  al; 

4  tfract  sockaddr  in  name; 

3  chartmf[1024]; 

6  1st  cc; 

7  inliengih; 

8  (tract  sockaddr  from; 

9  P  Create  jock*!  from  which  to  read.  *  / 

10  ss  *  socket  (AF  INET.SOCK  STREAM, 0); 

11  If  (  ss<0  )  { 

12  penotC opening  virtual  circuit  socket'*); 

13  exit(-l); 

14  ); 

15  /•  form  INET  socket  name  and  bind  it  to  ss  *  I 

16  name.sin_family  =  AF_INET; 

17  name.sin_addr.s_addr  =  INADDRANY; 

18  name-sin_post  =  0, 

19  if  (  bind(  sa,  &name,  afzeof(name)  )  )  { 

20  dosefss); 

21  perrorObinding  name  to  virtual  circuit  socket"); 

22  exii(-l); 

23  1 

24  P  Find  out  assigned  port  number  and  print  it  out  *  / 

25  length  =  sizeoffnatne); 

26  if  (  getsocknatne  (ss.&name.&lcngth)  )  ( 

27  pemxC  getting  socket  name"); 

28  exii(0); 

29  ) 

30  prinlfCSocket  has  port  #%<f\n".  niohs(natne.sin_pon)); 

31  P  listen  for  a  connection  from  the  client  process  vie  *  / 

32  printf ("...  waiting  for  connection  ...'n"); 

33  listen(st.l); 

34  si  *  acceptfss,  0.  Of, 

35  printf  0  connected  to  cLieniNT); 

36  printf  ("•••  waiting  for  messages  ...  \n“); 

37  do  { 

38  If  (  (cc=recv(s  1  ,buf.slzeof(buf).0)  )  <  0  ) 

39  perrorf  “receiving  virtual  circuit  packet"); 

40  if  (cc  >  0)  ( 

41  buflcc]  =  NULL; 

42  pnntfC message  received:  %s'n",  buf); 


primffmestage  received:  EOF  "); 
close  (si); 
close  (ss); 

printf(”...  disconnect'd"); 
exit  (0)  ; 


while  (TRUE); 


Fig.  2a:  !VS  (server) 


0  (Include  "def" 

1  maln(  arge,  argv  ) 

2  Int  arge; 

3  char  *argvQ; 

4  ( 

5  lat  sc; 

6  struct  sockaddr_in  server; 

7  struct  hostent  *hp,  *gelhostbynameO, 

8  char  bufI512]; 

9  lat  re; 

10  P  Create  socket  on  which  to  send.  •  / 

11  sc  =  socket  (AF_INET,SOCK_STREAM,0); 

12  If  (sc<0)  { 

13  perrorf  opening  virtual  circuit  socket"); 

14  exit(-l); 

15  ) 

16  P  Construct  name  of  socket  to  send  to  and  connect  to  it  *  I 

\1  server.  iin_family  »  AFINET; 

18  If  (  (hp  =  gethostbyname(argv[l)))  =  NULL  )  ( 

19  close(sc); 

20  fprinlf(stderr,  "Can't  find  host  %s'n",  argv[l]); 

21  exit(-l); 

22  ) 

23  bcopy  (  hp->h_addr,  A(server.sin_addr.s_addr),  hp->h_lengih); 

24  server.  sin_po«t  =  htons(atoi(argv[2])); 

25  if  (  connect(sc,  &  server.  slxeof(server))  <  0  )  { 

26  closefsc); 

27  perTorf  connecting  stream  socket"); 

28  exit(0); 

29  ) 

30  printfC* Connected  to  the  serverin'); 

31  printfCtype  message  (to  Finish  type  CTRL-D)'n”); 

32  P  Send  message.  •  / 

33  do  ( 

34  rc=read(0,buf.  stxeof(buf)); 

35  If  (send(sc,  buf,  re,  0)  <0  ) 

36  perrotf'tending  virtual  circuit  message"); 

37  ) 

38  while  (re  >  0); 

39  printf  ("EOF...  disconnect'd"); 

40  close(sc); 

41  exit  (0); 

42  ) 


Fig.  2b:  /VC  (client) 


Fig.  2:  INET  Virtual-circuit  programs 


terminal  Ts:  running 


the  server 


terminal  Tc:  running  the  client 


Fig.  3a:  Testing  using  two  terminals 


Fig.  3b:  Testing  using  two  windows 


Fig.  3:  Testing  the  server  and  the  client 


programs 


loop  (lines  37-52),  receiving  (lines  38-39)  and  displaying  (lines  40-43)  any  mes¬ 
sage  that  arrives  on  the  connection  until  the  client  sends  an  EOF  signaling  the  end 
of  conversation1.  Upon  receiving  the  EOF  message,  the  IVS  process  terminates 
(lines  44-50). 

In  Fig.  2b,  the  client  process  IVC  is  initiated  by  typing: 

X  IVC  host-name  port-number 

where  host-name  is  the  name  of  the  machine  running  the  server  process  IVS ,  and 
port-number  is  the  number  displayed  by  the  server  process.  The  IVC  process 
starts  by  creating  a  socket  sc  (lines  11-15),  forming  the  server_name  (lines  17-24) 
from  the  host  name  (argv[l])  and  the  port  number  (argv[2]).  Then  it  connects  the 
socket  sc  to  the  server-name  (lines  25-29)  and  enters  a  loop  (lines  33-38)  reading 
any  message  typed  on  the  keyboard  (line  34)  and  sending  it  to  the  server  process 
(lines  35-36)  until  CTRL-D  is  typed  to  end  of  conversation  with  the  server. 

To  test  how  the  two  programs  interact  with  each  other,  we  may  use  two  ter¬ 
minals  T,  and  Te  beside  each  other  as  shown  in  Fig.  3a.  We  use  terminal  T,  to 
run  the  server  program.  The  server  process  displays  the  selected  socket  number 
(e.g.,  Socket  has  port  #  1245)  and  waits  for  a  connection  by  the  client  process. 
We  use  the  second  terminal  Te  to  run  the  client  process  IVC  .  To  run  IVC  we 
provide  two  arguments:  the  remote  machine  name  and  the  port  number  where 
the  server  is  waiting.  After  the  client  process  is  connected  to  the  server  process  it 
reads  any  character  typed  on  the  keyboard  and  sends  it  out  to  the  server  process 
IVS.  Whatever  typed  on  Te  will  appear  instantly  at  T,.  For  example,  if  we  type 
the  message  “Hello  World!”  on  Te  it  will  appear  on  T,  as  “Message  received: 
Hello  World!”.  To  end  the  session  we  type  CTRL-D  on  Te  and  both  processes  will 
terminate  after  displaying  the  message  “EOF  .  .  .  disconnect” 

If  we  have  access  to  only  one  machine,  we  can  still  conduct  the  above  test, 
since  in  the  I  NET  domain  processes  in  the  same  machine  or  in  different  machines 
can  communicate  with  each  other.  We  use  terminal  T,  to  run  the  server  IVS  and 
‘In  UNIX  an  End-Of-File  is  signaled  by  typing  CTRL-D 


after  it  displays  the  port  number,  use  terminal  Ta  to  run  the  client,  where  the 
machine  name  is  the  one  running  both  the  server  and  the  client  processes. 

If  we  like  to  use  a  single  terminal  for  this  test,  we  need  to  create  two  “windows” 
as  shown  in  Fig.  3b.  Windows  can  be  created  using  any  available  window  man¬ 
agement  system  such  as  the  Berkeley  UNIX  4.3BSD  window  program  that  runs  on 
any  ASCII  terminal,  or  the  MIT  X-windowa  that  runs  on  a  variety  of  workstations 
including  SUNs  and  DEC  VAXs.  In  our  test,  the  top  window  is  used  as  terminal 
T ,  while  the  bottom  window  is  used  as  terminal  Tc. 


2.2  INET  Datagram  Programs 

To  create  a  datagram  socket  in  the  INET  domain  we  use: 

s  =  socket  (AFJNET.  SOCK.DGRAM.  0): 

Fig.  4a  shows  the  server  program  IDS  and  Fig.  4b  shows  the  client  program 
I  DC.  The  server  process  IDS  starts  by  creating  socket  ss  (lines  11-15),  binds  it 
to  am  INET  port  (lines  17-24)  amd  advertises  the  chosen  port  (lines  26-31).  Then 
enters  a  loop  (lines  34-46)  where  it  receive  messages  sent  by  the  client  process.  In 
contrast  to  the  virtual  circuit  program  ( IVS ),  this  program  does  not  execute  listen 
to  queue  connections  and  does  not  Accept  connections.  Also,  instead  of  using  recv, 
it  uses  recvfrom  to  read  the  incoming  messages  (line  35). 

In  Fig.  4b,  the  client  process  IDC  creates  a  socket  sc  (lines  11-15),  forms  the 
server  name  from  the  command  line  arguments  argv[l]  and  argv[2]  (lines  17-24). 
Then  sends  every  line  as  an  individual  datagram  (line  26-32)  using: 

sendto(sc.  message.  messageJength.  0.  ^server,  sizeof(server)): 

Note  that  the  server  name  ^server  is  attached  with  every  message  going  from 
process  IDC  so  that  the  server  process  IDS  can  identify  the  source  of  the  message. 
The  two  processes  terminate  when  CTRL-D  is  typed. 

To  test  these  two  program  we  follow  the  same  procedure  we  described  earlier 
for  testing  the  virtual  circuit  programs  IVS  and  IVC. 
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0  (Include  "def" 

1  mainO 

2  ( 

3  lot  si; 

4  (tract  sodcaddr_in  amt; 

5  char  bufll024]; 

6  lot  cc; 

7  lot  length; 

g  struct  sockaddr  from; 

9  int  fromlen; 

10  I*  Create  socket  from  which  to  read.  *  / 

11  „  =  socket  (AF_INET.SOCK_DGRAM,0); 

12  If  (  »»<0  )  {  ,  m 

13  petrorCopoh'S  tiujisin  socket  ); 

14  exit(— 1); 

15  1; 

16  /•  form  INET  socket  name  and  bind  it  to  ss  / 

17  name.sin_family  =  AF_INET; 

18  name.sin  addr.s_addr  -  INADDR_ANY; 

19  name.sinj»it  =  0; 

20  If  (  bind(  ss,  inaxnc,  ilzeoffname))  )  ( 

21  close(ss); 

22  perrorfbinding  name  to  datagram  socket  ). 

23  exit(-l); 

24  1  .  . 

25  r  Find  out  assigned  port  number  and  print  U  out  / 

26  length  =  alxeof(name); 

27  If  (  getsockname  (s«,4tname,Alengih)  )  { 

28  perrotf" getting  socket  name"); 

29  eait(O); 


30 

1 

31 

printf ("Socket  has  port  #%dV>",  ntohs(name.sm_port)); 

32 

/*  Read  from  the  socket  *  / 

33 

printfC-.  waiting  for  messages  ...W); 

34 

for  ( 

;:>  ( 

35 

If  (  (cc=recvfrom(  ss,buf,slicof(buf).  0.0.0))  < 

36 

pciTOri~receiving  datagram  packet"); 

37 

If  (cc  >  0)  ( 

38 

buficcl  =  NULL; 

39 

pnntf ("message  received:  %sW,  buO: 

40 

) 

41 

el»«{ 

42 

pnnlfC message  received:  UOF  exit"): 

43 

ciose(ss); 

44 

exil(0); 

45 

1 

46 

) 

47  ) 

Fig. 

4a:  IDS  (server) 

0  # Include  "def" 

1  main(  arge,  argv  ) 

2  int  arge; 

3  char  *argv[]; 

4  { 

5  int  sc; 

6  struct  sockaddr_in  server, 

7  (tract  hostent  *hp,  *gethostbynameO. 

8  char  bu/15121; 

9  lot  re; 

10  /*  Create  socket  on  which  to  send.  *  / 

11  sc  =  socket  (AF  INET.SOCK  DGRAM.O); 

12  If  (sc<0)  { 

13  perror("opening  datagram  socket"); 

14  exit(-l); 

15  ) 

16  /*  Construct  name  of  socket  to  send  to.  *  / 

17  server.sin_family  =  AF_INET; 

18  If  (  (hp  =  gethostbyname(argv[l]))  =  NULL  )  ( 

19  close(sc); 

20  fprintf(stderr,  "Can't  find  host  %s\n",  argv(I]); 

21  exit(-l); 

22  ) 

23  bcopy  (  hp->h_addr,  A(server.ain_addr.s_addr),  hp->h_lengih); 

24  server.sin_poit  =  htons(atoi(argv[2])); 

25  /*  get  data  from  user  and  send  it  to  the  server  process  *  / 

26  da  { 

27  rc=read(0,buf,  slaeoffbuf)); 

28  if  (sendto(sc,  buf,  re,  0,  Aserver,  slxeof(servcr))  <0  )  ( 

29  penorf sending  datagram  message"); 

30  } 

31  1 

32  while  (re  >  0); 

33  prinlf  ("EOF...  exirin"); 

34  closefsc); 

35  exit  (0); 

36  } 


Fig.  4b:  IDC  (client) 


Fig.  4;  INET  datagram  programs 
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3  Unix  Domain 


One  difference  between  the  UNIX  and  the  INET  domains  is  the  address  format.  In 
UNIX  domain,  addresses  are  file  path  names,  e.g.,  /tmp/filel.  To  create  a  stream 
socket  in  the  UNIX  domain  we  use: 

s  =  socket  (AF -UNIX.  SOCK_STREAM.  0): 
and  to  create  a  datagram  socket  we  use: 
s  =  socket  (AF -UNIX.  SOCK.DGRAM.  0): 

3.1  UNIX  Virtual-circuit  Programs 

Fig.  5  shows  the  code  for  the  server  program  UVS  and  the  client  program  UVC. 

The  UVS  process  creates  a  socket  ss  (lines  13-16),  binds  it  to  a  UNIX  file  name 
(lines  18-24).  Then  it  listens  to  socket  ss  (line  27),  and  when  a  client  process 
initiates  a  connection,  it  is  accepted  into  am  auxiliary  socket  si  (line  28).  After 
that  it  enters  a  loop  (lines  31-46)  to  receive  (lines  32-33)  and  display  messages 
sent  by  the  client  process  (lines  34-37)  until  am  EOF  is  received.  Upon  receiving 
EOF,  it  closes  the  socket  amd  deletes  the  associated  file  (lines  41-42). 

The  client  process  UVC  in  Fig.  5b  creates  socket  sc  (lines  8-12),  amd  forms  the 
server  name  (lines  14-15).  Contrast  this  with  the  INET  program!  IVC,  where  the 
server_name  is  not  known  until  execution  time  amd  is  formed  from  the  command 
line  arguements:  argv[l]  and  argv[2j.  After  connecting  to  the  server  process,  it 
repeatedly  accepts  the  user  input  and  sends  it  to  the  server  process  until  CTRL-D 
is  typed. 

To  test  the  interaction  between  UVS  amd  UVC ,  we  may  use  two  terminals 
(connected  to  the  same  host),  or  create  two  windows  on  one  terminal  as  described 
before.  In  invoking  the  client  process  UVC ,  we  provide  no  arguments,  since  the 
host  name  is  the  same  for  both  the  client  and  the  server  and  the  socket  is  bound 
to  a  path  name  known  to  the  client  process  in  priori. 


I.n.«  ■ 


.•1U 


..t  •  .1  .  «t 


0  (Include  "d cT 

1  mainO 

2  { 

3  strict 

4  strict 

5  cfamr 

6  tat 

7  lot  1 

8  lot 

9  lot 

10  char 


sockaddr_un  name; 
sockaddr  from; 
buf[1024); 
cc; 

frontiers; 

it; 

si; 

'pathname  =  "Amp/unxsock"; 


/*  Crtax e  socket  from  which  to  read.  *  / 
•a  -  socket  (AF  UNDC3OCK_STREAM,0); 
If  (  aa<0  )  { 

perrorf  opening  virtual  circuit  socket"); 

aiK-1); 


/*  form  name  and  bind  it  to  ss  *  / 
name.sun_family  =  AF_UNDC; 
strcpy(  name.  jun_paih,  pathname); 

if  (  bind(  ss,  iname,  sizeof(struct  sockaddr_un>- 1  )  )  ( 
close(ss); 

perrorf  binding  name  to  ss”); 
exit(-l); 


I*  listen  for  a  connection  from  the  client  process  uve  *  / 
ptintfC  —  waiting  for  connection  ...W); 
listen(ss.l); 

si  a  accept(ss,  0,  0); 

print/  ("connected  to  clientNn"), 

print/  f...  waiting  for  messages  ...  Nn"); 

do  { 

If  (  (cc=recv(sl.buf1alzeof(bu/).0)  )  <  0  ) 

perrorf recetvmg  virtual  circti'-t  message"); 

If  (cc  >  0)  ( 

buflcc]  =  NULL; 

prmtf ("message  received:  %s''n",  buf); 


pnntff message  received:  EOF  “); 

printff...  disconnecf'n"); 

close  (ss); 

unlinkfpathname); 

exit(O): 


while  (TRUE): 


Fig.  5m:  UVS  (server) 


0  (include  "deT 

1  mainO 

2  ( 

3  lot  sc; 

4  (tract  sockaddr_un  name; 

5  char  buf[512]; 

6  lat  re, 

7  /•  Creole  socket  on  which  to  send.  •  / 

8  sc  >  socket  (AF  UNTX.SOCK  STREAM.O): 

9  If  (se<0)  { 

10  perrorf  opening  virtual  circuit  socket"); 

11  exit(-l); 

12  ) 

13  /*  Construct  name  of  socket  to  send  to.  *  / 

14  name.sun_family  =  AF_UNDC; 

15  sircpy(  name.sun_path,  "Amp/unxsock"); 

16  If  (  connect(ac,  dtnarne,  aizeof(struct  sockaddr_un)-l  )  <  0  )  ( 

17  cloae(sc); 

18  perrorf  connecting  stream  socket"); 

19  exit(O); 

20  ) 

21  print/f Connected  to  the  serve i\n"); 

22  print/f...  type  any  message,  to  finish  type  CTRL-D...VT); 

23  I*  Send  message.  •  / 

24  d»  ( 

25  rc=rcad(0,buf,  slzeof(buf)); 

26  If  (send(sc.  buf,  rc,  0)  <0  ) 

27  perrorf  sending  virtual  circuit  message"); 

28  ) 

29  while  (re  >  0); 

30  print/  fEOF...  disconnect'*!"); 

31  close(sc); 

32  exit  (0); 


Fig.  5b:  (JVC  (client) 


Fig.  5:  UNIX  Virtual-circuit  programs 


/V-y" 


v-:-v 


3.2  UNIX  Datagram  Programs 

To  experiment  with  datagrams  in  the  UNIX  domain,  see  Fig.  6  for  the  server 
program  UDS  and  the  client  program  UDC.  The  server  process  UDS  creates  a 
socket  (lines  11-15),  binds  it  to  name  ((lines  17-23)  ,  and  without  waiting  for 
connections,  enters  a  loop  (lines  26-41)  where  it  receives  the  messages  sent  by  the 
client  process  and  displays  it  until  an  EOF  is  received. 

The  client  process  in  Fig.  6b  creates  a  socket  (lines  8-12)  and  sends  messages 
with  the  server  name  attached  to  each  mes8age(line  20).  To  test  the  interaction 
between  these  two  programs  we  follow  the  same  procedure  for  testing  the  virtual 
circuit  programs  in  the  UNIX  domain. 

4  Input  Multiplexing 

If  a  server  process  is  connected  concurrently  to  more  than  one  client  process,  it 
needs  to  multiplex  the  input  received  from  all  of  the  clients.  In  this  section  we 
present  an  example  in  the  INET  domain. 

Fig.  7  shows  the  code  for  a  server  program  called  IV.SEL  which  is  essentially 
the  IVS  program  except  that  it  serves  two  clients  instead  of  just  one.  The  program 
uses  the  select  system  call  to  monitor  the  arrival  of  data  from  any  of  the  clients. 
As  usual,  the  program  starts  by  creating  a  socket  (lines  9-13),  binds  it  to  a  port 
(lines  15-20),  announces  the  selected  port  (lines  22-27)  and  listens  for  connections 
(line  30).  It  accepts  the  first  connection  on  socket  si  (line  31)  and  the  second 
connection  on  socket  s2  (line  34).  Fig.  1  illustrates  the  relationship  between  the 
server  and  its  two  clients. 

To  monitor  the  two  sockets  si  and  s2  for  the  arrival  of  data,  we  use  a  bit  mask 
called  read-template  (line  3).  The  mask  is  cleared  using  the  FD-ZERO  macro 
(line  40)  and  we  add  si  and  s2  to  the  mask  using  the  FD.SET  macro  (line  41-42). 
The  select  call: 

nb  =  select  fFD-SETSIZE.  &read_template,  0.  0.  Await); 


0  ((Include  "deF 

1  mainO 

2  { 

3  struct 

4  char 

5  lot 

6  struct 

7  lat  I 

8  lot 

9  char 


struct  sockaddr  un  sockname; 

char  bufllQ24];~ 

lat  cc; 

struct  sockaddr  from; 

lat  fromlen; 

lat  ss; 

char  'pathname  =  "AmpAmxsock"; 

P  Create  socket  from  which  to  read.  •  / 
si  =  socket  (AF_UNtX,SOCK  DGRAM.O); 

If  (  sf<0  )  { 

perrorf opening  datagram  socket'); 
exit(-l); 

); 

P  form  sockname  and  bind  it  to  ss  *  / 
sockname.  sunfamiiy  =  AF_UNTX; 
strcpy(  sockname. sun_palh,  pathname); 

If  (  bind(  si,  isockname,  slzcof (struct  sockaddr_un)  -1)  )  ( 
close(ss); 

perns r<”bmding  sockname  to  SiH); 
exit(-l); 

) 

P  Read  from  the  socket  *  / 
printf  ("...  wailing  for  messages  ...  'n"); 

du  ( 

If  (  (cc=recv(ss.buf;slzeof(buf),0)  )  <  0  ) 

perrorfreceiving  virtual  circuit  message"); 

If  (cc  >  0)  ( 

buf(cc]  =  NULL; 

printf  (~  message  received:  %sVT.  buf); 


0  #lnclude  "deF 

1  mainO 

2  ( 

3  lat  sc; 

4  struct  sockaddr  un  name; 

5  char  bufl5 121; 

6  lat  re; 

1  t*  Create  socket  on  which  to  send.  *  / 

8  sc  =  socket  (AFUMX.SOCK  DGRAM.O); 

9  If  (ic<0)  { 

10  perrorf opening  datagram  socket"); 

11  exit(-l); 

12  } 

13  P  Construct  name  of  socket  to  send  to.  •  / 

14  namesunfamily  =  AF_UND(; 

15  strcpy(  name.sun_path,  "Amp/unxsock"  ); 

16  printfC...  type  any  message,  to  finish  type  CTRL-D...'n"); 

17  P  Send  message.  •  / 

18  do  { 

19  rcsrread(0,buf,  slzeoffbuf)); 

20  If  (sendtofsc,  buf,  re,  0,  kname, 

21  six eof( struct  sockaddr_un)-l)  <0  ) 

22  perrorf" sending  datagram  message"); 

23  } 

24  while  (re  >  0); 

25  printf  ("EOF...  exifin"); 

26  close(sc); 

27  exit  (0); 


printf("message  received:  EOF  "); 

printfF  -  exilNn"); 

close  (ss); 

unlink  (pathname); 

exit(0); 


Fig.  6b:  UDC  (client) 


while  (TRUE); 


Fig.  6a:  UDS  (server) 


Fig.  6:  UNIX  Datagram  programs 
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is  blocked  for  an  amount  of  time  equal  to  the  value  of  the  variable  wait  (in  Fig.  7, 
lines  37-38,  the  value  is  set  to  1  second).  When  the  select  call  returns,  then  either 
data  has  arrived  on  one  of  the  sockets,  the  wait  time-out  has  been  exceeded,  or 
an  error  has  occurred.  If  nb,  the  value  returned  by  select ,  is  greater  than  zero 
then  new  data  has  arrived  on  at  least  one  of  the  multiplexed  sockets.  We  use  the 
FD  JSSET  macro  to  test  whether  there  is  data  available  at  a  particular  socket  (line 
49  and  62).  For  example,  if  socket  si  has  data,  it  is  received  (lines  50-51)  and 
displayed  (lines  52-55). 

When  a  client  terminates  the  conversation  with  the  server  by  sending  an  EOF, 
the  corresponding  socket  should  not  be  added  to  the  bit  mask.  This  is  achieved  by 
setting  a  flag  (  e.g.,  eofl  in  line  59)  when  EOF  is  received.  When  a  flag  is  set,  the 
corresponding  socket  is  not  monitored  any  more  (e.g.,  line  41).  When  all  clients 
have  sent  an  EOF,  the  server  terminates  (lines  77). 

It  should  be  noted  that  if  the  value  of  wait  is  0,  the  select  statement  will  return 
immediately,  i.e.,  it  behaves  as  if  it  is  “polling”  the  sockets.  On  the  other  hand 
if  &wait  is  replaced  with  the  constant  NULL,  then  the  call  is  blocked  indefinitely 
until  data  arrives  on  one  of  the  monitored  sockets. 

To  test  the  IVJ5EL  program,  we  may  use  three  different  terminals  (alterna¬ 
tively,  we  may  use  three  windows  of  one  terminal)  connected  to  either  one,  two  or 
three  machines.  Assume  that  we  have  access  to  three  machines  named:  “ncsu”, 
“mcnc”  and  “unc”  and  we  are  using  three  windows  of  one  terminal  as  shown  in 
Fig.  8.  We  use  the  top  window  to  run  IVJSEL  process  on  “ncsu”,  the  middle  win¬ 
dow  to  run  a  client  process  JVC  on  the  “mcnc”  machine  and  the  bottom  window 
to  run  another  client  process  IVC  on  “unc”. 

We  should  notice  that  any  message  typed  on  the  middle  or  the  bottom  window 
will  instantly  appear  at  the  top  window.  To  terminate  a  client  type  CTRL-D  in 
the  corresponding  window.  The  IV-SEL  program  terminates  when  all  the  clients 
have  sent  EOF  messages  (lines  78-81).  The  test  may  be  conducted  using  other 
combinations  of  terminals,  windows  and  machines. 


0  (include  "def 

1  mainO 

2  { 

3  fd_iet  read_templtie; 

4  (tract  timeval  wail; 

5  (tract  sockaddr  in  server; 

6  char  bull  102);  * 

7  int  socle,  length,  sl,s2,  nb,  cc,  ready ,eofl,eof2; 

8  F  Crtatt  socktt  *  / 

9  sock  *  socket  (A F  INET.SOCK  STREAM ,0); 

0  If  (  sock  <  0  )  r 

1  perrorf  opening  stream  socket'); 

2  exit(0); 

3  ) 

4  F  Name  socktt  using  wildcards  *  / 

5  server. sin_fsmily  =  AF_INET; 

6  server. sin_«ddr.s_addr  ="  INADDR_ANY; 

7  server.sin~port  =  O, 

8  If  (  bintT  (sock, Aserver,slzeof(  server))  )  { 

9  perrorf 'binding  stream  socket'); 

0  ] 

:1  F  Find  out  assigned  port  number  and  print  it  out  *  I 

2  length  =  slleof(server); 

3  if  (  getsockname  (sock.&server.&length)  )  ( 

14  perrorfeetting  socket  name'); 

3  exit(0); 

16  ) 

17  printfC Socket  has  port  #%<hn".  ntohs(server.sin_port)); 

18  printfC. -waiting  for  connection  ...'*"); 

19  F  Start  accepting  connections  *  / 

>0  listen  (sock,  S); 

(1  sis  accept(sock,0,0); 

12  eofl=0; 

S3  printfC  connected  to  first  dienl'n"); 

14  s2  =  aocept(sock,0,0); 

S5  eof2=0; 

36  printfC  connected  to  second  clienfm'); 

37  wait.tv_sec  =  1; 

38  wait. tv  usee  =  O, 

39  do  {  _ 

40  FD  ZERO(&read  template); 

U  If  71eofl)  FD  SCr(sl.&read  template); 

12  If  (leof2)  FD  SET(s2.&read~teroplaie); 

13  nb  =  select(FD  SETS1ZE,  Steed  template,  (fd  set  *)  0,  (Id  set  •)  0,  Await); 

14  If  (nb  <0)  (  ~ 

15  pemwCselect'); 

16  exit(l); 

17  ) 

18  If  (nb  1=  0)  {  F  0  lime  out  •  / 

19  lf(FD  ISSET(sl,  &read_template)){ 

50  If  (  (cc=recv(*l,buf,slieof(buf),0)  )  <  0  ) 

51  perrorC receiving  vutual  circuit  packet'); 

52  If  (cc  >  0)  { 

53  buflccl  =  NULL; 

54  prinlfCmessage  from  sl:Nn  %s",  buf); 

55  ) 

56  clao  ( 

57  prinlfCmessage  from  si:  EOFVi  "); 

58  close(sl); 

59  eofl-1; 


lf(FD  ISSET(i2,  A  read  template))! 

If  (  (ecwrecv(i2,l>uf^lieof(buf),0)  )  <  0  ) 

perrorC  receiving  virtual  circuit  packet  "); 
If  (cc  >  0)  ( 

bufjee)  -  NULL; 

prinlfCmessage  from  s2:V»  %s",  buf); 


prinlfCmessage  from  s2:  EOPn  "); 

dose(s2); 

eof2=  1 ; 


while  (  leofl  44  leof2  ); 

printfC— exit—VT); 

close(sl); 

close(s2); 

exit(O); 


Fig.  7:  IV.SEL  program 


%  IVS  SEL 


Socket  has  port#  1234 
...  waiting  for  connection  ... 
connected  to  first  client 
connected  to  second  client 
message  from  si:  Hello,  first  client 
message  from  s2:  Hello,  second  client 
message  from  si :  EOF 
message  from  s2:  EOF 
...  exit... 

%  IVC  ncsu  1234 

Connected  to  server 

type  message(CTRL-D  to  finish) 

Hello,  ftart  client 

EOF...  disconnect 

%  IVC  ncau  1234 

Connected  to  server 

type  message(CTRL-D  to  finish) 

Hello,  second  client 

EOF...  disconnect 


5  Conclusion 


We  have  surveyed  the  basic  features  of  the  Interprocess  Communications  facilities 
available  in  the  popular  Berkeley  version  of  UNIX.  Then  we  presented  a  series  of 
simple  server/client  programs  that  can  be  used  as  a  model  of  writing  practical 
distributed  applications  over  a  network  of  computers  each  running  4.3BSD  or 
compatible  version  of  UNIX.  We  also  show  how  to  test  and  experiment  with  the 
programs  in  a  variety  of  configurations.  After  the  user  masters  the  concepts  and 
techniques  presented  in  our  progrsjns,  we  recommend  looking  at  the  source  code 
of  some  widely  used  utilities  such  as  the  remote  login  program  ( rlogin )  and  the 
file  transfer  program  (ftp).  While  the  paper  focuses  on  a  specific  system,  the 
experience  and  knowledge  gained  are  valuable  in  dealing  with  other  distributed 
systems  and  environments. 
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